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STATEMENT OF THE CASE 
Introduction 

This is an appeal under 35 U.S. C. § 134(a) from the Examiner's final 
rejection of claims 1 — 55. We have jurisdiction under 35 U.S.C. § 6(b). 
We reverse. 

Invention 

The invention relates to a system, device, and method for receiver 
access control in an internet television system that uses a push mechanism to 
distribute access control information from a distribution device to an access 
device (see Abstract). 

Exemplary Claim 

1. An access control method for an internet television system 
where each television channel is carried over a different 
multicast group, and subscribers join a particular multicast 
group in order to receive a particular channel, the access control 
method comprising: 

distributing multicast group access control information 
from a distribution device to a plurality of access devices for 
use by the access devices in authenticating subsequent requests 
by individual host devices to join a television channel multicast 
group in order to reduce delay in authentication when a host 
device changes television channels, wherein each access device 
is logically closer to the host device from which the access 
device receives the request than the distribution device; 

receiving, by one of the access devices, a subsequent 
request by one of the host devices to join the television channel 
multicast group in order to change television channels; 

determining, by the access device, whether the host 
device is authorized to join the television channel multicast 
group, and receive a particular television channel, based upon 
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the access control information distributed from the distribution 
device; and 

admitting, by the access device, the host device to the 
television channel multicast group if and only if the host device 
is determined to be authorized to join the television channel 
multicast group, 

whereby the access device receives the access control 
information before it is needed for determining whether the host 
device is authorized to join the multicast group, thereby 
facilitating changing channels by reducing authentication delay. 

Evidence and Rejection 
The Examiner rejects claims 1 —5, 7, 8, 11 — 18, 20, 21, 24 — 28, 30, 
31 ? 34-38, 40, 41, 44-48, 50, 51, 54, and 55 under 35 U.S.C. § 103(a) as 
being unpatentable over Mittra (US 5,748,736, May 5, 1998) and Widegren 
(US 6,621,793 B2, Sept. 16, 2003; claiming priority to U.S. Prov. Pat. App. 
60/206,186, May 22, 2000, and U.S. Prov. Pat. App. 60/246,501, Nov. 6, 
2000) (Ans. 3-16). 1 

ISSUE 

Did the Examiner show that, as applied in the rejection, Widegren 
qualifies as prior art under 35 U.S.C. § 103(a)? 



1 Claims 6, 9, 10, 19, 22, 23, 29, 32, 33, 39, 42, 43, 49, 52 and 53 are 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Mittra, 
Widegren, and other prior art references (Ans. 16—18). However, the 
rejections of these claims are not sustained for the same reasons discussed 
infra with respect to claims 1 -5, 7, 8, 11 - 18, 20, 21, 24-28, 30, 31, 34- 
38, 40, 41, 44-48, 50, 51, 54, and 55 under 35 U.S.C. § 103(a) as being 
unpatentable over Mittra and Widegren. 
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ANALYSIS 

The Widegren patent (Widegren '793) was filed after Appellants' 
patent application, which was filed September 13, 2000. However, Widegren 
'793 claims priority to two provisional patent applications, only one of 
which, 60/206,186 (Widegren '186), was filed before Appellants' patent 
application. 

A patent that claims priority to a provisional application has the same 
patent-defeating effect as though it had been filed on the date of the 
provisional. See In re Giacomini, 612 F.3d 1380, 1384 (Fed. Cir. 2010). 
However, "[a]n important limitation is that the provisional application must 
provide written description support for the claimed invention" or subject 
matter relied upon in the granted patent. See Giacomini, 612 F.3d. at 1383. 
"[A]n applicant is not entitled to a patent if another's patent discloses the 
same invention, which was carried forward from an earlier U.S. provisional 
application." Id. 

Therefore, in the instant appeal, Appellants are not entitled to a patent 
if Widegren '793 discloses the same invention, and that invention or subject 
matter has written description support in the Widegren '186 provisional 
application. See id. In other words, the subject matter of Widegren '793 
relied upon by the Examiner in rejecting claims 1 — 5, 7, 8, 1 1 — 18, 20, 21, 
24-28, 30, 31, 34-38, 40, 41, 44-48, 50, 51, 54, and 55 does not qualify 
as prior art under 35 U.S.C. § 103(a) unless there is written description 
support for that same subject matter in the Widegren '186 provisional 
application (i.e., unless the Widegren '186 provisional application discloses 
the same invention or subject matter as Widegren '793). 
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The Examiner "asserts that the 60/206,186 provisional application 
does support the cited feature/subject matter in the Widegren patent No. 
6,621,793 (see provisional application 60/206,186, page 9, IP Policy Control 
section, and pages 13 — 16)" (Ans. 19) (emphasis in the original). However, 
the Examiner's citation of five pages from the Widegren '186 provisional 
application, without more explanation, is not enough to show that the 
Widegren '186 provisional application provides the requisite written 
description support for the subject matter of Widegren '793 relied upon by 
the Examiner in making the rejection of claims 1 — 5, 7, 8, 11 — 18, 20, 21, 
24-28, 30,31,34-38, 40,41,44-48, 50, 51, 54, and 55 under 35 U.S.C. 
§ 103(a). 

The cited portions of the Widegren '186 provisional application and 
Widegren '793 differ in many ways. For example, in a section of Widegren 
'793 relied upon by the Examiner (Ans. 4 — 5), Widegren '793 discloses that 
"[p]olicy decisions are . . . 'pushed' to the GGSN [Gateway GPRS (Gateway 
General Packet Radio Service) Support Node] by a policy control function" 
(Widegren '793 col. 15, 11. 51 — 52) and that "[t]he authorized envelope 
allows the PCF [Policy Control Function] to pre-authorize a flow, before the 
UE [User Equipment] requests allocation of the resources ('push[]' model)" 
(Widegren '793 col. 16, 11. 56 — 58). However, the cited portions of the 
Widegren '186 provisional application do not explicitly state that they 
describe "pushing" policy decisions or "pre-authorization" of a flow using a 
policy control function (see Widegren '186 Prov. App. pp. 9 and 13 — 16 
(discussing IP Policy Control and Application of an IP Policy Architecture)). 
Therefore, the Examiner has not shown that the Widegren '186 provisional 
application provides the requisite written description support for the relied 
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upon subject matter of Widegren '793, and therefore, without further 
explanation, the Widegren '186 provisional cannot be relied upon to support 
the cited features and/or subject matter in Widegren '793. See Giacomini, 
612F.3d. at 1383. 

The Examiner does not present findings or reasoning showing that the 
cited portions of the Widegren '186 provisional application provide the 
requisite written description for the textual portions of the Widegren '793 
patent relied upon by the Examiner to reject Appellants' claim limitations. 
Accordingly, we do not sustain the Examiner's 35 U.S. C. § 103(a) 
rejections, all of which rely on Widegren '793. 

DECISION 

The Examiner's decision to reject claims 1 — 55 is reversed. 



REVERSED 



ELD 
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Background 
Abbreviations 




3G 



3 rf Generation 



1 



BS Bearer Service 

CC Call Control 

CN Core Network 

GPRS General Packet Radio Service 

GSM Global System for Mobile Communication 

IETF Internet Engineering Task Force 

IP Internet Protocol 

ISDN * Integrated Services Digital Network 

IFPC - IP Policy Control 

MO Mobile Originating Call 

MT .Mobile Terminal 

MTC .Mobile Terminated Call 

NS Network Service 

PDP Packet Data Protocol 

FDU Protocol Data Unit 

PS Packet Switched 

PSTN Public Switched Telephone Netwoik 

QoS Quality of Service 

RAB Radio Access Bearer 

BAN Radio Access Network 

RSVP Resource Reservation Protocol 

RT Real Time 

RTP Real Time Transport Protocol 

SAP Service Access Point 

SDU Service Data Unit 

SGSN Serving GPRS Support Node 
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SLA 


* Service Level Agreement 


UDP 


User Datagram Protocol 


TE 


Terminal Equipment 


TSFEC 


Traffic Specification 


UE * 


User Equipment 


UMTS 


Universal Mobile Teleconununication System 


IJTRA 


UMTS Terrestrial Radio Access 


UTRAN 


UMTS Terrestrial Radio Access Netwotk 
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Definitions 



External Applications: Applications on an external Host. 

User Equipment is a device allowing a user access to network services* For the 
purpose of 3GFP specifications the interface between the UE and the networic is the 
radio interface, A User Equipment can be subdivided into a number of domains, the 
domains being separated by reference points. Currently defined domains are the 
USXM and ME Domains. The ME Domain can further be subdivided into several 
components showing the connectivity between multiple functional groups. These 
groups can be implemented in one or more hardware devices. An example of such a 
connectivity is the TE — MT interface. 

The Radio Access Network domain consists of the physical entities, which manage 
the resources of the radio access network, and provides the user with a mechanism to 
access the core network. The Access Network Domain comprises roughly the 
functions specific to the access technology. 
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GTP tunnel (CN bearer service) 



* v J 

Scope ofPDP Context 

(primary/secondary) 




Remote 
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Title: 



IP Policy Architecture 



1. Introduction j 

This contribution proposes an IP Policy Architecture applicable to UMTS. 

2. Discussion j 

During the S2 R00 Drafting Meeting on QoS Issues which took place in 
Stockholm on May 9-1 1 , 2000,; the following requirement was identified following 
the discussion of AT&T's contribution entitled "Integration of SIP Signalling and 
Resource Management in 3GPP* (S2-000723): 

- the need for enabling mechanisms to transfer iocal policy decisions resulting 
from events in the application level (e.g., iocal SIP proxy) down to the IP. 
bearer level (GGSN). i 

The requirement suggests thej need for a suitable IP policy architecture which 
can interwork with the application iayer f formulate local policy decisions, and 
enforce policy in the IP beared level at the GGSN. 

i 

Recent developments in IETF surrounding IP policy framework and protocols 
reflect Industry thrust in providing services with appropriate quality of service to 
users who are willing to pay for better than best effort services. Some relevant 
IETF RFC's on the subject matter include [RFC2573] W A Framework for Policy* 
based Admission Control", [RFC2748] "The COPS Protocol*, [RFC2749] "COPS 
usage for RSVP", etc. Several Internet drafts are also being proposed which 

suggests possible extension^ to the framework. 

* 

It is envisaged that the IP po(icy framework employed in UMTS would conform to 
IETF standards to leverage the expertise and developments in the mainstream 
IP community, j 

On the other hand, there already exist working UMTS policy mechanisms within 
the UMTS specifications like; the TS23.107. As R00 is a smooth evolution from 

I 



i 
f 
i 
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R99 wherever possible, the UMTS policy mechanisms should continue to be 
used for control of the UMTS bearers. 



It is Important to allow separate 
policy framework, since the 
distinct QoS management roles 
This means that backward, as 
functionalities should be ensured 
the two would occur only at well 



ovolution for UMTS policy mechanisms and IP 
UMTS bearer services and IP bearer services have 
along pertinent segments In the end-to-end path. 
" as future compatibility for the respective 
It Is thus envisaged that interaction between 
defined points to minimize Interdependences. 



welt 



The IP BS Manager within the 
enforcement point during the 
000732). Also, the translation/rfi appin g 
the interworking between the 
UMTS and the external IP 
interaction between UMTS and 
theGGSN. 



GfGSN has been Identified as being a policy 

drafting meeting in Stockholm (endorsed S2- 
function within the GGSN must provide 
mechanisms and parameters used within the 
service (23.821 Section 9,2). Thus, the 
IP policy mechanisms should effectively occur in 



QoS 



bearer 



3- Proposal 



New text on UMTS and IP QoS 
element "IP Policy Control" is 



Policy Requirements is proposed. A new 
Introduced in the R00 QoS model 



also 



The following addftions/modifications are proposed for Chapter 9 of TR23.821 
Architecture Principles for Release 2000. 

As Figure 9-1 of TR23.821 (a modification of Figure 2 in TS23.1Q7) Is of 



informational nature s additions 
related protocol interfaces, are 



to the figure, i.e.. IP Policy Control element and 
attempted to help solve the QoS policy related 



concerns that have been identified so far. After a better understanding of 
requirements and subsequent agreement on appropriate solution w'rthin the QoS 
drafting group, it Is to be determined what and how aspects of the proposal can 

be included in the normative portion of the R00 standard. 

Nats: The proposed changes are shown against TR23.821 VO.2.0 incorporating the already 
approved (endorsed by the QoS drafting meeting in Stockholm) texts in Tdoc. S2-Q0O732 (IP BS 
Manager Capabilities) and Tdoc. 82^-000735 (QoS Control of the IP Bearer Service). 
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9 QoS 

[Note: The following sections are intended; to be included in TS23.107 (proposed chapter, if any): 

• 9,1.1 (new Chapter 4,4} ; 

* 9.1.2 fnew Piaster 4.5> j 
9,2 (Chapter 6.2) j 



9.1 Requirements j 

9.1.1 End-to-End QoS Negotiation Requirements 

(no change) . j 

i 

9-1.2 QoS Policy Requirements j 

• The existing UMTS policy mechanisms shall continue to hm used for control of the UMTS 
bearers: It is recognized that there already exists UMTS policy mechanisms within the existing UMTS 

specifications (fa T5?3.1Q7)t I 

i 
t 

• The IF policy framework employed in UMTS shall, as far as possible, conform to IETF "Internet 
Standards": The IETF policy framework shall be used for policy decision, authorization, and control 
of the IP leyel functionality, at both User and network level. This ensures conformance to mainstream 
IP developments, ; 

• There shall be separation between! the scope and roles of the UMTS policy mechanisms and the 
SP ppljcy framcworH: This is tq facilitate separate evolution of these functions. Interaction, between 
UM^S bearer services and IF bearer services shall only occur at well defined points, thus ensuring the 
separation of the two policy architectures. 

j 

9.2 QoS End-to-End Functional Architecture 

To provide QoS end-to-end, it is necessary to manage the QoS within each domain. An IP BS Manager is 
used to control the external IP bearer service. Due to the different techniques used within the IP network, 
this communicates to the UMTS BS manager through the Translation function. 

To enable coordination between events in the application layer and resource management in the IP bearer 
laver. an element called IP Policy Control is used as a logical policy decision element that is local to the 
network providing resources for the bearer nam, with protocol interfaces to local application 
servers/proxies, as welj as to the GGg^ls where policy .decisions arc enforced, 

The IP policy structure bases policy decisions only on information obtained from nodes / elements within 
the network which owns the resources for the bearer path, i.e., the local network, 

In addition, i j is p ossible to implement k policy decision element internal to the IP BS Manager in the 
CjGSN. The IP policy architecture does not mandate the policy decision point to be external tq the GgSN. 

Whenever resources not owned or controlled by the UMTS network are required to provide QoS, it is 
necessary to interwork with an extemai resource manager that controls those resources, 

i 

IP BS Manager I 
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The IF BS Manager uses standard IP mechanisms la manage the IF bearer sendee. These mechanisms may 
be different from mechanisms used within tie UMTS, and may have different parameters controlling the 
service. The translation/mapping function provides die interworking between the mechanisms and 
parameters used within the UMTS and the external IP bearer service, and interacts with the IP BS Manager. 

If an IF BS Manager exists both in the UE ^nd the Gateway node, it is possible that these IP BS Managers 
communicate directly with each other by uinng relevant signalling protocols. 

The required options in the table define the) minimum functionality that shall be supported by the equipment 
in order to allow multiple network operatoijs to provide interworking between their networks for end-to-end 
QoS. Use of the optional functions listed b^low, other mechanisms which are not listed (eg over- 
provisioning), or combinations of these mechanisms are not precluded from use between operators. 

i 

The IP BS Managers in the UE and GGSNj provide the following set of capabilities for the IP bearer level: 



Capability 




' ggsn 




Optional 


Required 


RSVP/1 NTSeRV^-— J 


Optional 


Optional 




Optional 


Required (*) 



Provision of the IP BS Manager is optional in the UE, and required in the GGSN. 

(*) Although the capability of IP policy enforcement is required within the GGSN, the control of IP policy 
through the GGSN is a network operator Choice. Where the APN is not located at the GGSNj the location of 
policy enforcement point is for further investigation. 



IP Policy Control 



The IP Policy Control is a logical local policy decision element which uses standard IP mechanisms to 
jrnplemenxpojjjcy pt t he „Ig M mPt, fever, Tfrcse mechanisms may be conformant to. f or example, the 
framework defined in IETF fRFC25731 f A Framework for Folicy-based Admission Control" where the IP 
Policy Control is effectively a Policy Decision Point fFDFTu The IP Policy Control make s decisions in 
regard to network based IP local policy using policy rules, and communicates these decisions to the IP BS 
M««^«Uhff <5fiSM, whjeft & the JP jjojicy Enforcement pojnt (PEf), 

A protocol interface between the IF Poiibv Control and local application servers/proxies (e.g. local SIP 
proxy*) support the transfer of policy related information from the application layer to the policy decision 
point. (Editorial note: The exact mechanisms, protocols whether proprietary or standardized, and haw 

they are used are for further stmhA \ 

» 

A protocol interface fretween,.the. IP Policy Control and GGSfr* support the transfer q{ informa^qp and focaj 
po^cy decisions between tf|e po^cy decision pow% and the Ig.g5 Manager jnjfrc OffSfrJ, (Editorial note; 
The exact mechanisms, protocols whether proprietary or standardized and how they are used are for 
further study. One possible candidate is the COPS protocol fHFC274Bl which describes a simple query 
and response protocol that can be ust 
its client tPEPl Where RSVP is used 
varianjsarryinz embegjied fi$VP infoi 



to exchange policy information between a policy server (PDP) and 
\s the signalling protocol in the JP bearer level, a CQPS protocol 
mon. i.e.. COPS-RSVP, defined in WFC27491 may be used A 



(Editorial note: Additionally, the IP Policy Control may have protocol interfaces to other devices (e.%^ 
AAA, bandwidth broke r) which support transfer of information (e.g.. authentication, availability of 
resources, etc. I for use in local policy decisions. These are for further study. ) 

f Editorial note; Where the access point of the APN is not located at the GGSN. the location of policy 
enforcement point is for further investigation. The IP policy architecture for cases where the access point 
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of the APN is located in a third party network c.g,. a corporate network, is for further study. ) 
Resource Manager 

Within the UMTS network* there is resource management performed by various nodes in the admission 
control decision. The resources considered here are under the direct control of the UMTS network. 

In IP Networks, it is also necessary to perform resource management to ensure that resources required for a 
service are available* Where the resources for the IP Bearer Service to be managed are not owned by the 
UMTS network, the resource management of those resources would be performed through an external 
resource management function for the IP network. 

In addition, where the UMTS network is also using external IP network resources as part of the UMTS 
bearer service (for example for the backbone bearer service), it may also be necessary to imerwork with an 
external IP resource manager. 

Figure 9*1 shows the scenario for control of an IP service using IP BS Managers in both possible locations 
in the UE and Gateway node and an external Resource Manager. The figure also indicates the optional 
communication path between thelPBS Managers in the UE and the Gateway node. 



local appt. 



(o.g., local 
SIP proxy) 



IP Policy 

Control 
^_ 



UE 



IPBS 



AdmTCap. 



UMTSBS f 



1 



UTRAN 



[Radio |< — i 

■HT, 



UTBA 

loh, PS M 



AdmJ 


Opt 








t 





ftaetfo 



runs 
MaBaqar 
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GN EDGE 
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Subsc . 
intrnl 



3 UMTS BS K 



(uBS 



CNBS 



linger I LMftngqgr 



tu NS 



Gateway 



Rasaurco 
Manager 



IPBS 



dmVCap. i l. 



UMTS BS 



f 



CNBS 

Managed 



BB NS 



Ext. IP 
Net*. 



gxt'.iP 
Sarvlca 
Control 



• protocol Interfaca 



i primitive 



Figure 9-1 : QoS management functions for UMTS bearer service in the control plane for an 

external IF Service 

Note; This does not cover the cases of a circuit switched service, or an IP service interworking with an 
ATM service at the gateway node. 

Editorial note: The actual split of the UE into separate elements (as described in TS 23.002 and TS 24.002) 
as well as the terminology regarding the UE elements and the distribution of functionalities between the UE 
elements is for further study. The modeling of the UE in TS 23.107 is not in line with TS 23.002 and TS 
24.002* which makes this clarification necessary. 
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Editorial notes The addition of policy functionality to th e QoS fram e work dcacribod here is for furthor 
otudyi The location of the policy related functionalities ia for further atudy as - w el U 

Editorial note: Elements external to the nodes are used to highlight and explain possible solutions to 
requirements that have been identifie d within the QoS drafting group. If elements or interfaces are specified 
or mandated within 3GPP. thev shall be included in the Reference Architecture. 
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Title: 



Application of IP Policy Architecture in UMTS 



1 INTRODUCTION 

This contribution considers the requirements as outlined in contribution S2-000723 and subsequent discussion, and-examines how 
those requirements could be met by application of policy control using the architecture proposed in contribution S2-0O084O. 

2 DESCRIPTION 



2.1 Requirements 

The requirements derived from contribution S2-000723 and subsequent discussions are identified below. Note that the derived, 
requirements as stated here have no status and are not recognised as formal requirements within 3G-PP. Furthermore, the 
requirements listed below are not assumed to be a definitive or complete set of requirements for the problem spaca identified in that 
contribution. : : 

Additional discussion Is recommended to increase the understanding of the specific requirements, which could enable an even 
broader range of solutions. In some cases, the requirements stated have been logically extended to cover additional functions, 
and/or possible alternate options have been proposed. Hence, this contribution is aimed to invite further discussion of both the 
proposed solution and the requirements. In the discussion below, the requirements are described in relation to a telephony call being 
placed over art IF based telephony network. However, the requirements for the controls are equally applicable for multimedia 
service, and for other types of applications entirely. 

1 . Restriction on establishment of UMTS bearers 

The requirement stated was that the conversational bearer may only be permitted for use with the AT&T telephony network. 
This requirement could logically be extended to have control over different types of bearer, dependent on the either the 
network they are connecting to (i.e. the APN), or the application that they are they are working towards. Although the former 
function may be useful, it is assumed that the latter case is the requirement. The requirement is logically extended to allow 
restriction of the bearer types to be controlled from any application. 

Theft of Service: 

There were several requirements that were raised under the banner of "theft of service". These are discussed individually, 

2. Access to resources within the telephony network is restricted by gating applied from the application level (i.e. an application 
server such as a SIP proxy can restrict access to the service network resources). The gating shall enforce that communication 
across the telephony network is only according to the connections approved from the application server. 

3. The telephony service based charging for data transfer (active phase of call) is not started until some time after the access 
bearer resources are reserved. The user cannot use these bearer resources without charge. The original stated requirement was 
that the user was not permitted to utilise access network resources prior to the start of charging. A proposed alternatives is: 

- The user shall be permitted to utilise access, network (e.g. UMTS) resources prior to the start of call charging, but that a 
charging rate specific for the access bearer would be applied for unauthorised data flow prior to the active phase. 

- Alternatively, the access bearer may be closed down if it is used fraudulently and no access network charging is applied. 
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* In addition, resources that are not authorised mud charged appropriately should not be permitted to be reserved. 



Note that the solution overview below describes the How of information between nodes to allow the policy decisions to be made in 
this way for this application. However, this contribution does not propose that the application is designed in this way, or that I? 
policy control should be used in the manner indicated. Rather, this contribution is simply giving an example of how policy conorol 
may be utilised within this architecture. 

However, alternative solutions may be used where various policy decisions are not outsourced to the IF Policy Control, but are 
made locally within die node. This contribution does not propose whether or not these decisions should be outsourced; it merely 
shows what is involved if they are outsourced. 

2J2 Solution Overview 

An overview of how the requirements can be met using "policy " mechanisms is discussed. Further detailed analysis can be 
performed when the requirements are clarified. The architecture for IF policy control specified in contribution S2-G00840 is 
applied* This architecture is shown in the figure below* 



IP Policy 




Resource 


Control 




Manager 




protocol Interface 



service primitive 



Figure 1 



Basic Architecture 



An information flow is described below, which is depicted in figure 2. 



The < 



s end hosts initiate the application, in this case a telephony call, using SIP signalling (1). The SIP signalling passes through a SIP 
proxy server within the network. The SIP session identifies the end points within the telephony network, denoted by their IP 
addresses. These IP addresses both reside within the addressing space of the telephony network (if the call does not terminate 
within this telephony network, the addresses are the gateway address within the telephony network which the bearer passes 

through). 

After the session has been started, the HE will ne*d to establish the QoS enabled access bearer for the data plane. This may occur 
during the session establishment as part of the preconditions for the session. The UE must select the access bearer type to be used 
based on the required characteristics, such as a conversational bearer, and it initiates a PDP context for the bearer leveL 
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The UE then requests establishment of the UMTS bearer (3). The translation/mapping function in the GGSN maps the UMTS 
bearer service into a detailed description of an IF service that is being provided to be user over the access network. The IF BS 
Manager contacts the IF Policy Control to determine whether this access IF bearer service is permitted to be established (4). The IF 
Policy Control may apply rules that restrict the use of specific access bearers dependent on network factors such as involvement of 
the Local SIP Proxy Server. Since the IP Policy Control has been informed that the Local SIP Proxy Server is in use for this ^ 
connection, the use of this bearer type is approved. 

Authority to establish the access bearer is separate from authority to transmit data into the telephony network* When the bearer is 
established, a "gate" is established at the GGSN that controls what data Is permitted to enter the telephony network (6). This gate is 
similar to the DS edge functionality, performing classification and policing of the data. The gate is controlled by data received from 
the application through the IP Policy Control. ; 

Prior to the session reaching the active phase, the UE may send data regarding the proposed usage of the access bearer to the 
GGSN. This information may be sent to the GGSN either through IF level signalling such as RSVP, or it could alternatively occur 
through PDF context signalling, as proposed in contribution S2-GG0842 for the uplink direction. For the downlink direction, the 
PDP context signalling already includes information about the TFT filters. In the figure below, the proposed bearer usage 
information is passed through PDF context signalling. i 

\ 

When the GGSN receives information about the traffic' usage for this bearer, the IF BS Manager may authorise the usage of the 
bearer (5). If the proposed usage does not agree with that authorised by the SIP proxy server, the GGSN may reject the bearer 
establishment, or the session establishment in the case jof RSVP. The SIP proxy server by this time must have supplied information 
to the IF Policy Control regarding the authorised traffic descriptor. , . . 

When the session reaches the appropriate state (i.e. th| active phase), the gate is opened to allow the data from the user to enter the 
network (7). : 

When the session is finished, the SIP proxy server revokes authorisation for both the session and the bearer level. It shall also close 
the "gate" that has been opened from the GGSN towards the telephony network. This action occurs at several different levels. The 
SIP proxy server terminates the session directly to the UE. It sends information to the policy server which results in the closing the 
gate at the GGSN. Finally, the SIP proxy server sends information to the policy server that results in the termination of the bearer, if 
the bearer termination has not already been initiated from the UE. 

The figure below shows a simple overview of the information flow between the network elements. The actual protocols and 

messages that would be used within this flow are for further study. 

( 

l 

i 
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An aim with this proposal is Chat the functions required 
applications. Therefore, the interface from the GGSN 
these functions* It is for further study what this protocol 



at the GGSN are not application specific, and may be required for different 
to the IP Policy Control should be a standardised interface for control of 
interface should be. 



The IP Policy Control may receive information from different applications that want to apply control. Although the function they 
are applying control to within the GGSN may be the same, the actual information supplied by the application and how that 
information is used may be different for different applications. Therefore* there may be a range of protocols between the IP Policy 
Control and the applications, although If is recommended mat applications with similar policy controls use the same protocol. 

Requirement 1 specifies that the use of specific acceis bearers will be restricted dependent on not just the application, but that the 
application (in this example the telephony call) determines whether the bearer type is authorised for use. To enable this control, a 
SIP proxy that is permitted to perform this authorisation (this must be a trusted node within the network with this responsibility) 
communicates to the IP Policy Control that the Local SIP Proxy Server is involved in the call for this UE. 



For scenarios where the UMTS bearer is being established 
network), the normal UMTS policy mechanisms may 



Requirement 3 states that resources that are not 
control information from the SIP proxy server 
session is in an appropriate state to authorise the 
Control, the IP Policy Control makes a decision on 
has approved the connection to be made at this tirne\ 



to other networks (i.e. where the APN is not accessed from the serving 
be used to apply control over establishment of the UMTS bearer services. 



authorised and charged appropriately should not be allowed to be reserved. The 
designates not only that the call is using the Local SIP Proxy Server, but also that the 
be irer service. When the IP BS Manager in the GGSN contacts the IP Policy 

not just whether the UE is authorised for the bearer type, but that the application 
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I 

i 

A possible alternative to this mechanism is to allow the bearer service to be established independent of the session state* In this case 
though* the charge applied for the access bearer would be different dependent on the current session state. If die session exists, there 
may be no access bearer charge, but if it doesnt exist, mere may be access bearer charges even if any data sent on the bearer is 
subsequently discarded, • 

i 
I 

Requirements specifies strict control the destination for data that is allowed to enter the telephony network. This may be because 
the telephony service could have destination dependent charging, and also because it may be performing resource reservation for 
the connection. In order to provide this control, the "gating* function in the GGSN must receive configuration data from the SIP 
proxy server via the IP Policy Control. ; 

If the UE does not provide signal proposed usage information for the connection, the network can only verify correct usage of the 
service network by checking the received data against the gate, and it cannot perform any additional resource management checks. * 
Reception of traffic profile information allows theTJE to verify its* intended usage is authorised, and permits additional negotiation • 
of IP level resources. 

r 

There are different actions within the policy enforcement that may be applied by the IP BS Manager. For example, if data is 
received that is not allowed through the gate, the IP BS Manager may take actions from discarding the data to terminating the 
bearer. The scope of policy enforcement options must be determined and considered when selecting the protocol to be used 
between the IP BS Manager and the IP Policy Control for each policy function. , 

3 CONCLUSION j 

i 

Within this overview, the following requirements have* been considered: 

1. Authorisation of UMTS bearers from the application. 

2. Control of opening and closing the gate for data to enter the service network, controlled from the application server through the 
policy server. • 

3. Control of the level and destination of data permitted to pass the gate and enter the service network, controlled from the 
application server through the policy server. [ 4 

It has been demonstrated that the IP Policy architecture proposed in S2-000841 can be used to perform policy control in a manner 
enabling these requirements to be fulfilled. Therefore^ it is proposed that contribution S2-00Q84I is accepted. 

i 
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Title: 



End-to-end QoS Related Information Carried in the PDF Context Message 



1 INTRODUCTION I 

In order to provide end-to-end QoS, resources need to be managed both in the UMTS network and in the external IP 
network. This contribution examines how die PDF context can be used to provide information that is necessary to 
control end-to-end QoS. The solution discussed in this document is applicable e.g. in the situadon where the UE does 
not provide an IP IS Manager. Note that this scenario was described in S2-000813. 

2 DISCUSSION 

j 

2.1 End-to-end QoS Related Reqtrirements 

The end-to-end QoS negotiation requirements listed in Section 9.1 of TR 23.821 include the following two 

requirements: 

* The UMTS QoS negotiation mechanisms usedjbr providing end-to-end QoS shall not make any assumptions about 
application layer signaling protocols. 

* The UMTS network shall be able to negotiate end~ta~end QoS also for mobile terminals and applications that are 
' not able to use QoS negotiation mechanisms other than the ones provided by UMTS. 

End-to-end QoS provisioning implies that resources in the external IP network need to be managed by the IP BS 
Manager in the GGSN. There are different IP resource management techniques available for the IP BS Manager to 
manage the IP resources, and some of these imply call admission control (CAC) functionality in the GGSN. In order 
for the GGSN to exercise CAC, information about the IP traffic (e.g. average and peak rates, required QoS and 
destination) may be necessary. '• 

The first requirement above implies that the initiating terminal cannot rely on application level signaling to check 
whether resources are available through the network and at the remote access. It follows that such a resource check 
must be performed at the bearer level. If the ijjE does not perform this bearer level request, then the GGSN may need 
to perform this function, and requires information about the destination IP address in order to perform a CAC decision. 

I 

The second requirement listed above implies! that end-to-end QoS must be provided even for terminals that do not 
implement the IP BS Manager functionality £*id only use UMTS BS Manager (e.g. PDP context signaling) to request 
resources within the UMTS network. j 

From these requirements and the discussion jabove it follows that the UE may need to signal end-to-end QoS related 
information to the GGSN. We propose that this piece of information be added as a new information attribute to the 
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Figure 1: Schematic 



2.2 Possible Extensions to the PDF Context 



diagram of the assumed network model 



The appropriate extension of the PDF context depends on the IP BS functionality that is actually implemented in the 
GGSN. Depending on the scope of the CAC in the GGSN, we distinguish the following two cases: 



the 



Case 1: CAC is based on the availability of resources over which the GGSN has control 

In this case the necessary QoS information mayjbe extracted from the existing PDP context by the Translation 
Function between the UMTS BS Manager and the IP BS Manager. In order to facilitate efficient IP resource usage and 
allow for policy decisions based on RSVP parameters, the PDP context could carry additional QoS related information 
specific to the IP bearer. For instance, such an Additional parameter can specify traffic descriptors and QoS 
descriptors. Such descriptors may be based on the ones associated with standard IP mechanisms, such as the 
differentiated services or integrated services. Alternatively, these descriptors may be based on the concept of the 
generic IP bearers. 

Case 2: The CAC is addition al ly based on the resource situation at the epress SLA 



In this case the destination IP address needs to 



be carried in the PDP context (apart from the descriptors of Case 1). 



services framework 
services framework 



The exact form of this additional QoS attribut4 in the PDP context is for further study. Candidates for the basis of this 
attribute include: 

parameters associated with the differentiated ; 
parameters associated with the integrated 
generic IP bearer parameters 
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3 PROPOSAL 

It is proposed that 3GFP S2 consider the argumentjs raised to extend the PDF context with an additional attribute 
having end-to-end QoS significance* 

We propose the following text to be added to Section 9 of TR 23.821: 
9.x IP Level End-to-end QoS Attributes 

[Editor's note: The contents of this section is intended to be included in a new subsection 6A.y ofTR 23 J 07] 

In order to allocate IP resources in an external m ttwork and to execute CAC the POP context may contain the 
optional attribute "End-to-end QoS". The content of this optional attribute is for further study. This attribute is 
transparent to the UMTS BS Manager, but allows the transport of IP QoS related information. 

It is also proposed that a new subsection be added to Section 6.4 of the document TR. 23.107 M QoS Concept and 
Architecture**: 

6A.y IP Level End-to-end QoS Attributes 
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